As of late 2014, NAT has also been introduced.  NAT should only be used if the clients are dual stacked to IPv6 in an effort to reduce the amount of NAT that is needed.  Private IP space should also be used when no other alternative exists.

An enterprise that decides to use RFC1918 can do so without any coordination with other enterprises. RFC1918 addresses will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other within their own private internet.

The DoIT managed campus network and customers that connect directly to it can be considered a single enterprise. Campus connected entities that perform their own routing, such as Computer Science or UW Hospital and Clinics, might consider their own internal network as an enterprise. DoIT CAN NOT guarantee reachability outside of campus network enterprise network although reachability CAN be negotiated with those enterprise networks as mentioned in the above paragraph. When considering RFC1918 solutions, it is important to consider if the service may need to communicate with devices outside the enterprise network you are connected to.

For example, the Department of Basketweaving connects to the campus network in two or more physically diverse locations. The department wishes to move its printers to RFC1918 space. This department depends solely on the campus network enterprise for direct communication. If this department wishes to share its printers with, for example, Computer Science, these connections will traverse two enterprise networks (the campus network and the Computer Science network) and coordination prior to deployment is highly recommended.

---

Scenarios where the RFC1918 service MUST not be used

• Servers and services that need access to the public internet.

---

Scenarios where the RFC1918 service MIGHT be used, only after careful consideration

• examples:
  * Cluster computing, where all external network connections are handled by a server with a public IP address.
  * A/V controller systems
  * Printers
  * HVAC controllers
  * Backend services
  * Specialized lab equipment (microscopes, etc)
  * End users that need access to the public internet [NAT will be required]

---

Additional Notes regarding the proposed RFC1918 service.

• The VPN service counts as "on campus" so devices that need to be shared with people off-campus who can use the VPN service are ok.
• The need for an added proxy to retain current functionality is a strong indicator that RFC1918 service as defined is not an appropriate solution.
• While the use of RFC1918 (non-public) IP addresses MIGHT prevent direct connections between these devices and the Internet outside of the campus network, this does not replace the need for an appropriately configured firewall to protect sensitive or vulnerable data or services. Depending on design, the machines may still be reachable from campus or from other machines in the same broadcast domain.

---

Allocation strategy for the RFC1918 IP service

A query was sent to WiscNic contacts in September 2008 regarding current RFC1918 utilization on campus. Based on feedback from that query, we are recommending that;

• DoIT manage and allocate from 10.128/9 [10.128.0.0 -> 10.255.255.255] for use on the campus network enterprise.
• Allocations will be requested and tracked in the same manner being used for public IPv4 allocations.
• Any other RFC1918 space, including parts of 10/9 not mentioned above, 172.16/12, 192.168/16, will not be routed, managed or allocated by DoIT.

---

DNS for the RFC1918 service

• Forward and reverse IP resolution SHOULD NOT work from an off campus address.
• Authoritative reverse IP resolution MUST be supported. For the DOIT recursive anycast DNS service, this will be supported by forwarding RFC1918 requests to the DOIT authoritative DNS service. Other campus DNS servers MUST forward RFC1918 requests to the DOIT recursive anycast DNS service in order to resolve RFC1918 IPs.
• Forward IP resolution -SHOULD- be accomplished by the creation of a more specific namespace 'local' for which all RFC1918 host information will be stored. Example; for doit.wisc.edu, we would create fourth level domain local.doit.wisc.edu. Hosts would be created under this domain [mcfly.local.doit.wisc.edu]. Restrictions on lookups in that domain can be decided administratively on a per-zone basis with a zone ACL, which is more widely supported in DNS software in comparison to the split-horizon / BIND views method. This also gives a knowledgeable user an immediate hint based on URL that the intention is for non-routability.