0. Checklist for WLCG site system administrators and networking teams 

1. This checklist is the HEPiX Pv6 working group’s current list of issues to be considered. We welcome feedback from sites on the contents of this list according to their experiences during the transition. Updates and additions will be made as required. 

2. (i)  Make an addressing plan
   One of the most important design decisions for a site team creating an IPv6 deployment plan is to create an IPv6 addressing plan. This should match the acceptable usage and access policy of the organisation. It also needs to include consideration as to how to manage a dual- stack network, possibly reviewing the security aspects of the existing IPv4 infrastructure. IPv6 address space (typically a /48 - default size as in RFC3177 [1]) will have been allocated to the site by its NREN or other ISP. Consideration needs to be given to the routing and switching design of the network [2]. The number of subnets, the routing architecture, and the address allocation within subnets etc. all need to be included.

3. (ii)  Decide whether to use DHCPv6 or SLAAC (+dDNS)
   The second most important decision - and very much linked to the one above - to be made by a site networking team is whether or not to use one of the important new features of IPv6, i.e. the end-system use of IPv6 Stateless Address Autoconfiguration (see RFC4862 [1]). You may prefer that server systems have fixed IPv6 addresses (either manual or DHCPv6), while the use of SLAAC for servers should be accompanied by dynamic DNS. Looking at these three protocols (SLAAC, dDNS and DHCPv6) from a security standpoint (see RFC4942 [9]), the main difference in available spoofing/hijacking channels is due to the fact that configuration via the ICMPv6 Router Advertisement protocol is multicast to the network segment and received by hosts.

3. (iii)  Ensure all security/network monitoring/logging tools are IPv6-capable
   All monitoring and logging tools (commercial, open-source, home written), at any hierarchical level of the organisation (central and end-user), need to be evaluated and tested for operation on IPv6. They should properly deal with longer addresses, the new address syntax, multiple addresses per network card, etc. Tools should be certified to work in a dual-stack environment, with the ability to simultaneously monitor both stacks. Tools analysing log files should be capable of parsing address syntax for both stacks.

4. (iv)  Filter IPv6 packets that enter and leave your network/system
   IPv4-only networks include end systems where IPv6 is enabled by default. This may open significant security breach opportunities if intrusion detection systems and Firewalls are not handling IPv6 traffic correctly. Consideration should be given to the various options of setting up system- or network-level filtering. See also the following items for hints on the performance implication of IPv6 filtering and the need to keep these measures synchronised with the IPv4 ones. Switching off/filtering IPv6 at the network level isn’t a realistic option anymore, while specific legacy systems may need to be protected by disabling their IPv6 stack. The specific issue of filtering of ICMPv6 packets is dealt with in the next topic.

5. (v)  Filter ICMPv6 messages wisely
   Many ICMPv6 messages have an essential role in establishing or maintaining IPv6 communication. Some ICMPv6 messages can therefore not be blocked (unlike in IPv4). Other types of ICMPv6 messages may lead to security issues if allowed through the site border. See RFC4890 [1] for a full discussion and detailed advice. Our group’s knowledge base [3] offers RFC4890-compliant example rules for IOS and JunOS devices.

6. (vi)  Allow special-purpose IPv6 Extension Headers only if needed
   Although the requirement for IPv6 stacks to fully implement the handling of all IPv6 Extension Headers (for IPSEC, Mobile IP, etc.) has been lifted (per RFC5095 [1]), the processing of these may open up end systems and sites to a large vulnerability space. Packets with inappropriate, unexpected or malformed Extension Headers should be filtered. The processing of Extension Headers can significantly complicate the task of firewall ACLs, especially if headers extend beyond the first packet fragment. Sites need to verify whether running ACLs have the ability to process Extension Headers and block unwanted extension headers as prescribed by RFC7045 [1].

7. (vii)  Use synchronised IPv4/IPv6 access rules
   The management of production dual-stack networks, especially when reacting to security incidents, is much simpler if semantically equivalent firewall rules (site and end-system) are deployed for both stacks. Having to always update lists in tandem is error-prone and may leave unnoticed security holes (or unwanted denial of service) behind. Lacking the capability of networking firmware to express rules in common lists, one may think of generating such lists from a common template. The fact that there are IPv6-specific measures to take (see e.g. the ICMPv6 point above) may lead sites to assemble entirely new configurations. These should never forget any of the existing IPv4 rules. The option between modeling IPv6 lists on existing IPv4 lists or taking the IPv6 rollout as a chance to refresh both lists should be evaluated.

8. (viii)  Deploy RA-Guard or otherwise deal with Rogue RAs
   Neighbor Discovery and Router discovery are two important new features of IPv6 (actually ICMPv6). The fact that they are generally based on IPv6 multicast exposes sites to several different security problems. Rogue routers or attackers can send out false router announcements (RAs) to persuade end systems to send packets to them for routing allowing for lack of privacy and man in the middle attacks. RFC6104 describes the issue in detail and covers several ways of addressing the issue. The only sure-fire measure is to apply a filter on all local area network (LAN) active parts, e.g. by having them accept RAs only from a single endpoint of the network, via the RA-Guard (RFC6105) protocol. Making sure all of the network infrastructure supports RA-Guard may take a significant amount of effort (or equipment replacement), so the other measures described in RFC6104 may need to be deployed in the meantime.

(ix) Do not be tempted by transition technologies
Think carefully before using or allowing tunnelling technologies as an IPv4→IPv6 transition tool. These usually do not save IPv4 address space. Their additional complexity doesn’t gain any real advantage over the simpler approach of deploying dual-stack systems and offers a wide space for security exploits. NAT64/DNS64 (RFC6146/6147 [1]) may become a useful tool when the transition process is almost complete and the burden of managing IPv4 on the LAN can be eventually removed.

(x) Filter/disable IPv6-on-IPv4 tunnels
As we don’t recommend using such tunnels (see above), the IPv4 protocol number 41 (IPv6 encapsulation) should be disabled and filtered throughout the site network. 

[1] All Internet Engineering Task Force Requests For Comments (RFC) documents are available from URLs such as http://www.ietf.org/rfc/rfcNNNN.txt where NNNN is the RFC number, for example http://www.ietf.org/rfc/rfc2460.txt

[2] There is abundant reference material at:

http://www.internetsociety.org/deploy360/resources/ipv6-address-plannin…
and https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-C…