anchor.diff:      <strong>Note</strong>: CF does not support a RedHat Enterprise Linux OS stemcell. This is due to an inherent security issue with the way RedHat handles user namespacing and container isolation.
   </p>
   
  -## <a id='networking'></a>Container Networking ##
  +## <a id='networking'></a>Inbound and Outbound Traffic from CF
   
   ### <a id='net-overview'></a>Networking Overview ###
   
  -To isolate applications and control outgoing traffic, each Garden container uses a dedicated virtual network interface that consists of a pair of Ethernet addresses: one visible to the application instance running in the container, and the other visible to the host VM’s root namespace. The pair is configured to use IP addresses in a small and static subnet. Applications are typically allowed to invoke other applications in CF only by leaving the system and re-entering through the load balancer positioned in front of the CF routers. 
  -
  -<%= vars.container_security1 %>
  -
  -When an application instance starts, the [Diego cell](./diego/diego-architecture.html#cell-components) on the host VM allocates an IP address and assigns an arbitrary port to the application container. The application uses the `PORT` environment variable provided in the container environment to determine which port to listen on. Because the host assigns a random value to the `PORT` environment variable, the value is generally unique for each application instance.
  -
  -A host VM has a single IP address. If you configure the deployment with the cluster on a VLAN, as recommended, then all traffic goes through the following levels of network address translation, as shown in the diagram below.
  +A host VM has a single IP address. 
  +If you configure the deployment with the cluster on a VLAN, as recommended, 
  +then all traffic goes through the following levels of network address translation, as shown in the diagram below.
   
   * <strong>Inbound</strong> requests flow from the load balancer through the router to the host cell, then into the application container. The router determines which application instance receives each request.
   
  
positive.code: CF mitigates against container breakout and denial of service attacks in the following ways:
  
  * CF uses the full set of [Linux namespaces](http://manpages.ubuntu.com/manpages/wily/man7/namespaces.7.html) (IPC, Network, Mount, PID, User, UTS) to provide isolation between containers running on the same host. The User namespace is not used for privileged containers.
  * In unprivileged containers, CF maps UID/GID 0 (root) inside the container user namespace to a different UID/GID on the host to prevent an application from inheriting UID/GID 0 on the host if it breaks out of the container. 
  	* CF uses the same UID/GID for all containers.
      * CF maps all UIDs except UID 0 to themselves. CF maps UID 0 inside the container namespace to `MAX_UID-1` outside of the container namespace.
      * Container Root does not grant Host Root permissions.
  
negative.code: 
  ### <a id='config-traffic'></a>Network Traffic Rules ###
  
  Administrators configure rules to govern container network traffic. 
  This is how containers send traffic outside of CF and receive traffic from outside, the Internet.
  These rules can prevent system access from external networks and between internal components
  and determine if apps can establish connections over the virtual network interface.
  
  Administrators configure these rules at two levels: 
  
  * Application Security Groups (ASGs) apply network traffic rules at the container level. <%=vars.app_sec_groups_link%>
  * Container networking policies determine app-to-app communication. 
    Within CF, apps can communicate directly with each other, but the containers are isolated from outside CF.
    For information about administering container network policies, 
    see [Administering Container Networking](../adminguide/container-networking.html).  
  
  ## <a id='security'></a>Container Security###
  
  