A lot of work has been undertaken inside the 6NET project to investigate and report on the existing IPv6 mechanisms. This section looks closely on the potential risks deploying the mechanisms and reports on the security issues raised by the use of them with the overall aim to create awareness to the people that manage the migration to an IPv6 network.

The next sections reviews general issues arising by the use of tunnels especially automatic tunnels and operational issues of NAT-PT.

Generally, any form of tunnelling poses a security threat to a network. If set up properly tunnels can effectively circumvent and undermine any security features present to guard the network like access control lists and firewalls. In a way they drill a hole through them since these security measures only “see” the outer layer of the packets, which might be well within the permitted parameters but have nothing at all to do with the contents/protocol/traffic inside. So if this traffic reaches a tunnel end-point inside the guarded network it is decapsulated and from there can potentially be very harmful since within a network itself, defence levels are usually much lower. Tunnels used for IPv6 deployment are no exception.

During the migration from IPv4 to IPv6 three different kinds of tunnels may be used: IPv6-in-IPv4,IP(v4)-in-IPv6 or other layer tunnels. In terms of general management of tunnels, RFC 4087 [RFC4087] describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks.