IPv6 in Condor, a developer's perspective

*draft*

See also HowToEnableIpvSix .

{section: The Rules}

*: *Do not write code to create or parse sinful strings.*  Sinful strings are now weird and complex beasts and you will almost certainly miss important edge cases.  Use the existing interfaces.  You probably want condor_sockaddr::to_sinful or condor_sockaddr::from_sinful.

*: *Do not use sockaddr_in or sockaddr_in6.*  condor_sockaddr exists specifically to shield you from needing to worry about those.

{section: The Big Picture}

{subsection: condor_sockaddr}

The data structure holding information about a IP address/port pair is =condor_sockaddr=, which handles juggling sockaddr_in and sockaddr_in6.  You shouldn't worry if a given address is IPv6 or IPv4, just use the condor_sockaddr opaquely.  If you need a textual but still opaque representation, use condor_sockaddr::to_sinful and condor_sockaddr::from_sinful to create and parse sinful strings.  Sinful string are human readable and thus appropriate to use in log messages.

IPv6 addresses require a scope id, identifying which network interface to use.  This solves the problem of a single machine being part of two or more private ("link local") networks using the same address space.  However, it just creates a new problem: if all you have is an IP address, how do you know which interface to use.  The answer: we have no idea.  Some tools allow the user to specify the scope ID in a variety of inconsistent ways.  This is why NETWORK_INTERFACE is required for IPv6; we use the NETWORK_INTERFACE to identify the scope ID.

{subsection: condor_netaddr}

=condor_netaddr= exists to encapsulate the idea of a subset. It's built on top of condor_sockaddr, adding a count for how many bits to mask off. At the moment it's only being used to validate that a subset string can be parsed, but should eventually be used in any situation where Condor is checking that a given address is within a given subset (ie security).