UW-Madison IPv6 Deployment and IPv4 Exhaustion Planning
This list is a summary of conversations with various campus workgroups of possible strategies to deal with the deployment of IPv6 in the eventuality of IPv4 address runout. This is by no means an official plan or course of action, but should be well representative of how issues may pan out.
IPv6 Deployment Strategies for the University of Wisconsin at Madison, considering the eventual exhaustion of IPv4 resources.
- Keep IPv4 working without NAT for as long as possible via prudent allocation, reclamation
of underutilized resources, and using private (RFC1918) address space for specialized applications.
- Ensure new network hardware / services will be natively IPv6 ready, even if it won't be enabled on day 1.
- Acquire IPv6 capability as part of normal procurement cycles, as a cost-savings measure.
- Test IPv6 in various roles and capacities before large scale deployment.
- Deploy native IPv6 alongside IPv4 in a sensible fashion, coordinated with each network administrator.
- Security Issues / Packet filtering must be considered upon initial deployment, not tacked on later.
- Deploy reasonable alternative transition technologies such as 6to4, Teredo, NAT-PT, IVI, proxies, etc
to aid connectivity to/from legacy hosts, but NOT as a primary IPv6 connectivity mechanism.
- IPv4 may have to exist "forever" via NAT as address space runs out. All services clients that need long-term global reachability must use IPv6.
- Internal applications, backend systems, and other devices which do not need off-campus reachability on IPv4 should move to using internal rfc1918 address space to free up IPv4 resources for critical services.