Refer to the following information if you encounter any issues while planning and deploying IPv6 at your site. For specific planning tasks, see Chapter 2, Planning for Using IPv6 Addresses in Planning for Network Deployment in Oracle Solaris 11.4.
The existence of an IPv6 interface does not necessarily mean the system is using IPv6. The interface is not brought up until you actually configure an IPv6 address on that interface.
For example, the following output of the ifconfig command shows that the inet6 net0 interface has not been marked as UP and has an address of ::/0,meaning an IPv6 interface is not configured.
# ifconfig net0 inet6 net0: flags=120002000840<RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2 inet6 ::/0
The in.ndpd daemon still runs on the system but does not operate on any IP interfaces that do not have an addrconf address configured.
If you cannot upgrade your existing equipment, you might need to purchase IPv6-ready equipment. Check the manufacturer's documentation for any equipment-specific procedures that you might be required to perform to support IPv6.
You cannot upgrade certain IPv4 routers for IPv6 support. If this situation applies to your topology, as an alternative, you can physically wire an IPv6 router next to the IPv4 router. Then, you can tunnel from the IPv6 router over the IPv4 router. For instructions on configuring IP tunnels, see Chapter 5, Administering IP Tunnels in Administering TCP/IP Networks, IPMP, and IP Tunnels in Oracle Solaris 11.4.
You might encounter the following issues when preparing services for IPv6 support:
Certain applications, even after being ported to IPv6, do not turn on IPv6 support by default. You might have to configure these applications to turn on IPv6.
A server that runs multiple services, some of which are IPv4 only and others that are both IPv4 and IPv6, can experience problems. Some clients might need to use both types of services, which can lead to confusion on the server side.
If you want to deploy IPv6, but your current Internet Service Provider (ISP) does not offer IPv6 addressing, consider the following alternatives:
Hire another ISP to provide a second line for IPv6 communications from your site. This solution is expensive.
Get a virtual ISP. A virtual ISP provides your site with IPv6 connectivity but no link. Instead, you create a tunnel from your site, over your IPv4 ISP, to the virtual ISP.
Use a 6to4 tunnel over your ISP to other IPv6 sites. For an address, you can use the registered IPv4 address of the 6to4 router as the public topology part of the IPv6 address. For more information, see How to Configure a 6to4 Tunnel in Administering TCP/IP Networks, IPMP, and IP Tunnels in Oracle Solaris 11.4.
By nature, a tunnel between a 6to4 router and a 6to4 relay router is insecure. The following types of security problems are inherent in such a tunnel:
Though 6to4 relay routers do encapsulate and decapsulate packets, these routers do not check the data that is contained within the packets.
Address spoofing is a major issue on tunnels to a 6to4 relay router. For incoming traffic, the 6to4 router is unable to match the IPv4 address of the relay router with the IPv6 address of the source. Therefore, the address of the IPv6 system can easily be spoofed. The address of the 6to4 relay router can also be spoofed.
By default, no trusted mechanism exists between 6to4 routers and 6to4 relay routers. Thus, a 6to4 router cannot identify whether the 6to4 relay router is to be trusted or even if it is a legitimate 6to4 relay router. A trusted relationship between the 6to4 site and the IPv6 destination must exist. Otherwise, both sites leave themselves open to possible attacks.
These problems and other security issues that are inherent with 6to4 relay routers are explained in RFC 3964, Security Considerations for 6to4 (http://www.rfc-editor.org/rfc/rfc3964.txt). See also RFC 6343, Advisory Guidelines for 6to4 Deployment (http://www.rfc-editor.org/rfc/rfc6343.txt) for updated information about using 6to4.
Generally, you should consider enabling support for 6to4 relay routers for the following reasons only:
Your 6to4 site intends to communicate with a private, trusted IPv6 network. For example, you might enable 6to4 relay router support on a campus network that consists of isolated 6to4 sites and native IPv6 sites.
Your 6to4 site has a compelling business reason to communicate with certain native IPv6 systems.
You have implemented the checks and trust models that are suggested in Security Considerations for 6to4 (http://www.ietf.org/rfc/rfc3964.txt) and Advisory Guidelines for 6to4 Deployment. (http://www.ietf.org/rfc/rfc6343.txt).