anchor.diff:  
   ### <a id="consistency-without-tls"></a>Without TLS Enabled
   
  -In this mode, the Diego Route Emitters on each cell send route registration messages that include instructions for the Gorouter to send unencrypted requests to the app instance. If the Gorouter does not receive an update for the route within the time-to-live (TTL) interval, the route is pruned from the Gorouter's routing table. See [TLS to Apps and Other Back-End Services](#tls-to-back-end) for details.
  +In this mode, the Diego Route Emitters on each cell send route registration messages that include instructions for Gorouter to send unencrypted requests to the app instance. If Gorouter does not receive an update for the route within the time-to-live (TTL) interval, the route is pruned from Gorouter's routing table. See [TLS to Apps and Other Back-End Services](#tls-to-back-end) for details.
   
   This pruning method was developed before the alternative was available.
   
  
positive.code: 
  This mode is newer and has the following benefits:
  
  - Improved availability for applications by keeping routes in the Gorouters routing table when TTL expires
  - Increased guarantees against misrouting, by validating the identity of back ends before forwarding requests
  - Increased security by encrypting data in flight from the Gorouter to back ends
  
  In this mode, the Diego Route Emitters send a modified route registration message to NATS that includes a unique identifier for the app instance, as well instructions to use TLS when communicating with the instance. See [TLS to Apps and Other Back-End Services](#tls-to-back-end) for details.
  
  Before forwarding traffic to an app instance, the Gorouter initiates a TLS handshake with an [Envoy proxy](https://www.envoyproxy.io/) that runs in each app container and listens on port 8443. In the TLS handshake, the Envoy proxy presents a certificate generated by Diego for each container which uniquely identifies the container using the same app instance identifier sent by the Router Emitter, configured in the certificate as a domain Subject Alternative Name (SAN).
  
  If the Gorouter confirms that the app instance identifier in the certificate matches the one received in the route registration message, the Gorouter forwards the HTTP request over the TLS session. If the instance identifiers do not match, the Gorouter transparently retries another instance of the app. If the TTL of the failed back end has expired, Gorouter prunes the route to it from its routing table.
  
  The following table explains how the Gorouter keeps routes in its routing table after TTL has expired, as long as TLS handshakes continue to succeed.
  
  <table border="1" id="when-tls-prune" class="nice">
    <tr><th>&nbsp;</th>
  
negative.code: 
  ### <a id="forward-client-cert"></a> Forward Client Certificate to Applications
  
  Applications that require mutual TLS (mTLS) need metadata from client certificates to authorize requests. Cloud Foundry supports this use case without bypassing layer-7 load balancers and Gorouter.
  
  The HTTP header `X-Forwarded-Client-Cert` (XFCC) may be used to pass the originating client certificate along the data path to the application. Each component in the data path must trust that the back-end component has not allowed the header to be tampered with.
  
  