Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
Extracted elements (28)
A single HTTP-based RI is used for both DNS and HTTP redirection (rather than separate interfaces) so that CDN operators only need to deploy, monitor, manage, and build tooling for one interface regardless of UA redirection method. This also avoids needing to embed CDNI-specific data inside DNS/HTTP requests.
The RI is limited in scope to Recursive Request Redirection only; Iterative Request Redirection does not invoke any RI interaction between CDNs, so this document does not address it. Loop detection in the RI only covers control-plane loops; data-plane loops are explicitly out of scope.
The scope dictionary in RI responses allows a dCDN to indicate that a response applies to a wider IP range than the specific UA in the request, reducing RI request volume and latency for the uCDN. This is a deliberate trade-off that also increases the risk of topology probing as noted in Section 5.
When DNS-based redirection with HTTPS is used, any Redirection Target returned must be capable of completing a TLS handshake with the UA; the new target domain may not match the original URL domain, potentially triggering UA security warnings without operational precautions such as private key distribution to dCDN surrogates.
A cached RI response MUST NOT be reused unless the new UA request would generate an identical RI request (except for c-ip when the UA IP falls within the scope iprange of the original response). The uCDN SHOULD use the most recent cached response when multiple cached responses have overlapping scopes.
A dCDN MUST NOT return a Redirection Target that is a Request Router if the dns-only key is set to True in the RI request. CDNs MUST include dns-only set to True on any cascaded RI requests when the original request had dns-only=True.
A single RI request or response MUST contain only one of the 'dns' or 'http' keys. Requests MUST contain a cdn-path key. If max-hops is not present, there is no limit on CDN hops.
A uCDN SHOULD only include in RI requests information absolutely necessary for content delivery. Cookies in particular SHOULD NOT be conveyed in RI requests due to security and privacy sensitivity.
An implementation of the CDNI Redirection interface MUST support TLS transport per RFC 2818 and RFC 7230. In environments requiring protection, mutually authenticated TLS MUST be used by both dCDN (server) and uCDN (client), following RFC 7525 guidance.
Each CDN MUST insert its CDN Provider ID into the cdn-path of every RI request it originates or cascades. A dCDN MUST check cdn-path on receipt and MUST reject any RI request already containing its own Provider ID, responding with error-code 502.
For internationalized domain names in DNS redirection requests and responses, the qname and cname fields MUST use the ASCII-compatible encoded (ACE) A-label representation as defined in RFC 5890.
RI request and response bodies MUST be JSON objects conforming to RFC 7493 (I-JSON). Senders MUST encode all keys in lowercase; receivers MUST ignore unknown or invalid keys.
RI requests MUST use MIME type application/cdni with ptype=redirection-request; RI responses MUST use application/cdni with ptype=redirection-response, as specified in RFC 7736.
The uCDN MAY decide not to return, override, or alter any HTTP headers defined by sc-(<headername>) keys before sending the HTTP response to the UA, because dCDN-supplied cache headers (e.g., sc-(cache-control)) could cause the UA to bypass the uCDN in future requests.
Transit CDNs MUST NOT propagate an RI request downstream if the number of CDN Provider IDs in cdn-path (before adding the transit CDN's own ID) is equal to or greater than max-hops. The dCDN MUST respond with error-code 503 if cdn-path length exceeds max-hops.
RI requests transmit the UA's IP address and requested URI to the dCDN. If a uCDN queries multiple candidate dCDNs via the RI, those not ultimately selected still learn UA IP addresses and URIs they would not otherwise see. IP anonymization (e.g., masking last bits) is possible but reduces routing effectiveness and may prevent correlation of RI requests with subsequent UA requests.
CDN Provider ID uniquely identifies a CDN in the cdn-path; its format is 'AS' followed by the CDN's AS number, a colon, and a numeric qualifier ensuring uniqueness when one AS runs multiple CDNs (e.g., 'AS64496:0').
DNS Redirection Request 'dns' dictionary mandatory keys: resolver-ip (String, DNS resolver IP), qtype (String, 'A' or 'AAAA'), qclass (String, e.g., 'IN'), qname (String, FQDN). Optional keys: c-subnet (CIDR IP/prefix of UA), dns-only (Boolean, forces dCDN to return surrogate RTs only via DNS).
DNS Redirection Response 'dns' dictionary mandatory keys: rcode (Integer, DNS response code per RFC 6895), name (String, FQDN). Optional keys: a (List of IPv4 addresses), aaaa (List of IPv6 addresses), cname (List of FQDNs), ttl (Integer, seconds, default 0). If cname is present, a and aaaa MUST NOT be present.
HTTP Redirection Request 'http' dictionary mandatory keys: c-ip (UA IP address), cs-uri (Effective Request URI), cs-method (HTTP method), cs-version (HTTP-version string). Optional: cs-(<headername>) keys for individual HTTP header fields from the UA request, each <headername> in lowercase.
HTTP Redirection Response 'http' dictionary mandatory keys: sc-status (Integer, HTTP status code, typically 302), sc-version (String), sc-reason (String), cs-uri (String, original requested URI), sc-(location) (String, URI of the Redirection Target). Optional sc-(<headername>) keys for additional response headers.
The CDNI Redirection Interface (RI) uses HTTP POST from uCDN to dCDN's RI URI, encapsulating User Agent request attributes in a JSON body. The dCDN responds with HTTP 200 and a JSON body containing Redirection Target attributes and caching policy.
The 'error' dictionary contains: error-code (Integer, mandatory, three-digit) and reason (String, optional). Error class 1xx = informational, 4xx = uCDN error, 5xx = dCDN error. Defined codes include 501 (unable to retrieve metadata), 502 (loop detected), 503 (max hops exceeded), 504 (out of capacity), 505 (delivery protocol not supported), 506 (redirection protocol not supported).
The 'scope' response-only dictionary contains key 'iprange' (List of CIDR strings) indicating the set of UA IP subnets for which the RI response may be reused without a new RI request, provided the response is still fresh per HTTP Cache-Control.
Top-level JSON keys in RI messages: 'dns' (DNS request/response attributes), 'http' (HTTP request/response attributes), 'scope' (response only, cacheability scope), 'error' (error details), 'cdn-path' (list of CDN Provider IDs traversed), and 'max-hops' (request only, integer hop limit).
IANA has created the 'CDNI RI Error response code' subregistry within the CDNI Parameters registry. Values are three-digit integers with registration policy 'Specification Required'. Initial entries (100, 400, 500–506) are registered by RFC 7975. New registrations must provide Code, Reason, Description, and Specification.
IANA has registered two new Payload Types in the CDNI Parameters registry for use with the application/cdni MIME type: 'redirection-request' (for RI request messages) and 'redirection-response' (for RI response messages), both defined by RFC 7975.
The RI enables a single uCDN client to probe a dCDN's edge topology by making repeated RI requests for different content and UA IP addresses. The scope dictionary amplifies this risk by reducing the number of queries needed to infer surrogate assignments. The same information would be harder to gather without the RI, requiring distributed machines with varied IP addresses.