Checklist for developers
This checklist is the HEPiX Pv6 working group’s current list of issues to be considered. We welcome feedback from developers on the content of this list according to their experiences during the transition. Updates and additions will be made as required.
(i) Plan for extensive testing
The syntactic change of the core IP networking code in the IPv4→IPv6 transition is large enough to oftentime justify the refactoring of larger portions of code. The semantic 1 → N change may be forcing some rethinking at the design level. A possible temptation here is to provide parallel sections of code that handle the IPv6 case only: a few other reasons why this may not be a good idea are listed below. In any case, there is an implicit expectation that a change that should be affecting the transport layer of the network only should cause no ripple in the upper layers, i.e. that the perceived responsiveness, performance and reliability of the code remain unchanged. Extensive stress-testing should therefore be planned on IPv6- ported code.
(ii) Respect the sysadmin protocol preferences
Code that binds and connects IP sockets is suddenly faced with making choices that used to be delegated to the operating system or networking-capable libraries. Lists of addresses may be received in a given order, but it’s now the responsibility of the socket-handling code to iterate and re-iterate on the list, handle exceptions and possibly operate in parallel on various entries to implement some form of ‘happy-eyeballs’  algorithm. As the ordering of both source and destination addresses established at the system level by the system administrator2 may have security implications, developers should go the extra mile to keep that ordering even if they have to reshuffle the list for any reason. Applications should allow users to prefer/enable either IPv4 or IPv6 via configuration, but should always honor the system-level administrator’s choice by default.
(iii) Port all existing security measures
Fresh new code that hasn’t been tested broadly and in the wild is per se attractive to anyone looking for malicious exploits. Especially in the case where IPv6-specific code or processes are developed for parallel deployment with well-proven IPv4 code, one should make sure that any security measure, filter or wisdom that was included in the code for the IPv4 case isn’t simply forgotten for IPv6. While it may not be immediately apparent, all constructs that are meaningful for IPv4 have their translation or counterpart for IPv6.
 See RFC6555 
 Via /etc/gai.conf, ip addrlabel or their equivalent