diff options
Diffstat (limited to 'doc/rfc/rfc7975.txt')
| -rw-r--r-- | doc/rfc/rfc7975.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc7975.txt b/doc/rfc/rfc7975.txt new file mode 100644 index 0000000..b450474 --- /dev/null +++ b/doc/rfc/rfc7975.txt @@ -0,0 +1,1963 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Niven-Jenkins, Ed. +Request for Comments: 7975 Nokia +Category: Standards Track R. van Brandenburg, Ed. +ISSN: 2070-1721 TNO + October 2016 + + + Request Routing Redirection Interface for + Content Delivery Network (CDN) Interconnection + +Abstract + + The Request Routing interface comprises (1) the asynchronous + advertisement of footprint and capabilities by a downstream Content + Delivery Network (CDN) that allows an upstream CDN to decide whether + to redirect particular user requests to that downstream CDN; and (2) + the synchronous operation of an upstream CDN requesting whether a + downstream CDN is prepared to accept a user request and of a + downstream CDN responding with how to actually redirect the user + request. This document describes an interface for the latter part, + i.e., the CDNI Request Routing Redirection interface. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7975. + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 1] + +RFC 7975 Request Routing Redirection October 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Interface Function and Operation Overview . . . . . . . . . . 4 + 4. HTTP-Based Interface for the Redirection Interface . . . . . 6 + 4.1. Information Passed in RI Requests and Responses . . . . . 8 + 4.2. JSON Encoding of RI Requests and Responses . . . . . . . 9 + 4.3. MIME Media Types Used by the RI Interface . . . . . . . . 11 + 4.4. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 12 + 4.4.1. DNS Redirection Requests . . . . . . . . . . . . . . 12 + 4.4.2. DNS Redirection Responses . . . . . . . . . . . . . . 14 + 4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17 + 4.5.1. HTTP Redirection Requests . . . . . . . . . . . . . . 17 + 4.5.2. HTTP Redirection Responses . . . . . . . . . . . . . 19 + 4.6. Cacheability and Scope of Responses . . . . . . . . . . . 22 + 4.7. Error Responses . . . . . . . . . . . . . . . . . . . . . 24 + 4.8. Loop Detection and Prevention . . . . . . . . . . . . . . 28 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 5.1. Authentication, Authorization, Confidentiality, and + Integrity Protection . . . . . . . . . . . . . . . . . . 29 + 5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 6.1. CDNI Payload Type Parameter Registrations . . . . . . . . 31 + 6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 31 + 6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 31 + 6.2. RI Error Response Registry . . . . . . . . . . . . . . . 31 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 7.2. Informative References . . . . . . . . . . . . . . . . . 34 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + + + +Niven-Jenkins, et al. Standards Track [Page 2] + +RFC 7975 Request Routing Redirection October 2016 + + +1. Introduction + + A Content Delivery Network (CDN) is a system built on an existing IP + network that is used for large-scale content delivery, via + prefetching or dynamically caching content on its distributed + surrogates (caching servers). [RFC6707] describes the problem area + of interconnecting CDNs. + + The CDNI Request Routing interface outlined in [RFC7336] is comprised + of: + + 1. The asynchronous advertisement of footprint and capabilities by a + downstream CDN (dCDN) that allows an upstream CDN (uCDN) to + decide whether to redirect particular user requests to that dCDN. + + 2. The synchronous operation of a uCDN requesting whether a dCDN is + prepared to accept a user request and of a dCDN responding with + how to actually redirect the user request. + + This document describes an interface for the latter part, i.e., the + CDNI Request Routing Redirection interface (RI). + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document reuses the terminology defined in [RFC6707]. + + The following additional terms are introduced by this document: + + Application-Level Redirection: The act of using an application- + specific redirection mechanism for the request routing process of + a CDN. The Redirection Target (RT) is the result of a CDN's + routing decision at the time it receives a content request via an + application-specific protocol response. Examples of an + application-level redirection are HTTP 302 Redirection and Real + Time Messaging Protocol (RTMP) [RTMP] 302 Redirection. + + DNS Redirection: The act of using DNS name resolution for the + request routing process of a CDN. In DNS Redirection, the DNS + name server of the CDN makes the routing decision based on a local + policy and selects one or more Redirection Targets (RTs) and + redirects the User Agent (UA) to the RT(s) by returning the + details of the RT(s) in response to the DNS query request from the + User Agent's DNS resolver. + + + + +Niven-Jenkins, et al. Standards Track [Page 3] + +RFC 7975 Request Routing Redirection October 2016 + + + HTTP Redirection: The act of using an HTTP redirection response for + the request routing process of a CDN. The Redirection Target (RT) + is the result of the routing decision of a CDN at the time it + receives a content request via HTTP. HTTP Redirection is a + particular case of application-level redirection. + + Redirection Target (RT): The endpoint to which the User Agent is + redirected. In CDNI, an RT may point to a number of different + components, some examples include a surrogate in the same CDN as + the request router, a request router in a dCDN, or a surrogate in + a dCDN. + +3. Interface Function and Operation Overview + + The main function of the CDNI Redirection interface (RI) is to allow + the request routing systems in interconnected CDNs to communicate to + facilitate the redirection of User Agent requests between + interconnected CDNs. + + The detailed requirements for the Redirection interface and their + relative priorities are described in Section 5 of [RFC7337]. + + The User Agent will make a request to a request router in the uCDN + using one of either DNS or HTTP. The RI is used between the uCDN and + one or more dCDNs. The dCDN's RI response may contain a Redirection + Target with a type that is compatible with the protocol used between + the User Agent and uCDN request router. The dCDN has control over + the Redirection Target it provides. Depending on the returned + Redirection Target, the User Agent's request may be redirected to: + + o The final surrogate, which may be in the dCDN that returned the RI + response to the uCDN or another CDN (if the dCDN delegates the + delivery to another CDN); or + + o A request router (in the dCDN or another CDN), which may use a + different redirection protocol (DNS or HTTP) than the one included + in the RI request. + + The Redirection interface operates between the request routing + systems of a pair of interconnected CDNs. To enable communication + over the Redirection interface, the uCDN needs to know the URI + (endpoint) in the dCDN to send CDNI request routing queries. + + The Redirection interface URI may be statically preconfigured, + dynamically discovered via the CDNI Control interface, or discovered + via other means. However, such discovery mechanisms are not + specified in this document, as they are considered out of the scope + of the Redirection interface specification. + + + +Niven-Jenkins, et al. Standards Track [Page 4] + +RFC 7975 Request Routing Redirection October 2016 + + + The Redirection interface is only relevant in the case of Recursive + Request Redirection, as Iterative Request Redirection does not invoke + any interaction over the Redirection interface between interconnected + CDNs. Therefore, the scope of this document is limited to Recursive + Request Redirection. + + In the case of Recursive Request Redirection, in order to perform + redirection of a request received from a User Agent, the uCDN queries + the dCDN so that the dCDN can select and provide a Redirection + Target. In cases where a uCDN has a choice of dCDNs, it is up to the + uCDN to decide (for example, via configured policies) which dCDN(s) + to query and in which order to query them. A number of strategies + are possible, including selecting a preferred dCDN based on local + policy, possibly falling back to querying an alternative dCDN(s) if + the first dCDN does not return a Redirection Target or otherwise + rejects the uCDN's RI request. A more complex strategy could be to + query multiple dCDNs in parallel before selecting one and using the + Redirection Target provided by that dCDN. + + The uCDN->User Agent redirection protocols addressed in this document + are: DNS redirection and HTTP redirection. Other types of + application-level redirection will not be discussed further in this + document. However, the Redirection interface is designed to be + extensible and could be extended to support additional application- + level redirection protocols. + + For both DNS and HTTP redirection, either HTTP or HTTPS could be used + to connect to the Redirection Target. When HTTPS is used to connect + to the uCDN, if the uCDN uses DNS redirection to identify the RT to + the User Agent, then the new target domain name may not match the + domain in the URL dereferenced to reach the uCDN; without operational + precautions, and in the absence of DNSSEC, this can make a legitimate + redirection look like a DNS-based attack to a User Agent and trigger + security warnings. When DNS-based redirection with HTTPS is used, + this specification assumes that any RT can complete the necessary + Transport Layer Security (TLS) handshake with the User Agent. Any + operational mechanisms this requires, e.g., private key distribution + to surrogates and request routers in dCDNs, are outside the scope of + this document. + + This document also defines an RI loop prevention and detection + mechanism as part of the Redirection interface. + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 5] + +RFC 7975 Request Routing Redirection October 2016 + + +4. HTTP-Based Interface for the Redirection Interface + + This document defines a simple interface for the Redirection + interface based on HTTP [RFC7230], where the attributes of a User + Agent's requests are encapsulated along with any other data that can + aid the dCDN in processing the requests. The RI response + encapsulates the attributes of the RT(s) that the uCDN should return + to the User Agent (if it decides to utilize the dCDN for delivery) + along with the policy for how the response can be reused. The + examples of RI requests and responses below do not contain a complete + set of HTTP headers for brevity; only the pertinent HTTP headers are + shown. + + The RI between the uCDN and dCDN uses the same HTTP interface to + encapsulate the attributes of both DNS and HTTP requests received + from User Agents, although the contents of the RI requests/responses + contain data specific to either DNS or HTTP redirection. + + This approach has been chosen because it enables CDN operators to + only have to deploy a single interface for the RI between their CDNs, + regardless of the User Agent redirection method. In this way, from + an operational point of view, there is only one interface to monitor, + manage, develop troubleshooting tools for, etc. + + In addition, having a single RI where the attributes of the User + Agent's DNS or HTTP request are encapsulated along with the other + data required for the dCDN to make a request routing decision, avoids + having to both 1) try to encapsulate or proxy DNS/HTTP/RTMP/ + etc. requests and 2) find ways to somehow embed the additional CDNI + Request Routing Redirection interface properties/data within those + end-user DNS/HTTP/RTMP/etc. requests. + + Finally, the RI is easily extendable to support other User Agent + request redirection methods (e.g., RTMP 302 redirection) by defining + additional protocol-specific keys for RI requests and responses along + with a specification about how to process them. + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 6] + +RFC 7975 Request Routing Redirection October 2016 + + + The generic Recursive Request Redirection message flow between + Request Routing systems in a pair of interconnected CDNs is as + follows: + + User Agent CDN B RR CDN A RR + |UA Request (DNS or HTTP) | | + |-------------------------------------------------->| (1) + | | | + | |HTTP POST to CDN B's RI | + | |URI encapsulating UA | + | |request attributes | + | |<------------------------| (2) + | | | + | |HTTP Response with body | + | |containing RT attributes | + | |of the protocol-specific | + | |response to return to UA | + | |------------------------>| (3) + | | | + | Protocol-specific response (redirection)| + |<--------------------------------------------------| (4) + | | | + + Figure 1: Generic Recursive Request Redirection Message Flow + + 1. The User Agent sends its (DNS or HTTP) request to CDN A. The + Request Routing System of CDN A processes the request and, + through local policy, recognizes that the request is best served + by another CDN, specifically CDN B (or that CDN B may be one of a + number of candidate dCDNs it could use). + + 2. The Request Routing System of CDN A sends an HTTP POST to CDN B's + RI URI containing the attributes of the User Agent's request. + + 3. The Request Routing System of CDN B processes the RI request and, + assuming the request is well-formed, responds with an HTTP "200" + response with a message body containing the RT(s) to return to + the User Agent as well as parameters that indicate the properties + of the response (cacheability and scope). + + 4. The Request Routing System of CDN A sends a protocol-specific + response (containing the returned attributes) to the User Agent, + so that the User Agent's request will be redirected to the RT(s) + returned by CDN B. + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 7] + +RFC 7975 Request Routing Redirection October 2016 + + +4.1. Information Passed in RI Requests and Responses + + The information passed in RI requests splits into two basic + categories: + + 1. The attributes of the User Agent's request to the uCDN. + + 2. Properties/parameters that the uCDN can use to control the dCDN's + response or that can help the dCDN make its decision. + + Generally, dCDNs can provide better routing decisions given + additional information about the content request, e.g., the URI of + the requested content or the User Agent's IP address or subnet. The + information required to base a routing decision on can be highly + dependent on the type of content delivered. A uCDN SHOULD only + include information that is absolutely necessary for delivering that + type of content. Cookies in particular are especially sensitive from + a security/privacy point of view and in general SHOULD NOT be + conveyed in the RI Requests to the dCDN. The information necessary + to be conveyed for a particular type of request is expected to be + conveyed out of band between the uCDN and dCDN. See Section 5.2 for + more detail on the privacy aspects of using RI Requests to convey + information about UA requests. + + In order for the dCDN to determine whether it is capable of + delivering any requested content, it requires CDNI metadata related + to the content the User Agent is requesting. That metadata will + describe the content and any policies associated with it. It is + expected that the RI request contains sufficient information for the + Request Router in the dCDN to be able to retrieve the required CDNI + Metadata via the CDNI Metadata interface. + + The information passed in RI responses splits into two basic + categories: + + 1. The attributes of the RT to return to the User Agent in the DNS + response or HTTP response. + + 2. Parameters/policies that indicate the properties of the response, + such as, whether it is cacheable, the scope of the response, etc. + + In addition to details about how to redirect the User Agent, the dCDN + may wish to return additional policy information to the uCDN. For + example, the dCDN may wish to return a policy that expresses "this + response can be reused without requiring an RI request for 60 seconds + provided the User Agent's IP address is in the range 198.51.100.0 -- + 198.51.100.255". + + + + +Niven-Jenkins, et al. Standards Track [Page 8] + +RFC 7975 Request Routing Redirection October 2016 + + + These additional policies split into two basic categories: + + o Cacheability information signaled via the HTTP response headers of + the RI response (to reduce the number of subsequent RI requests + the uCDN needs to make). + + o The scope of a cacheable response signaled in the HTTP response + body of the RI response, for example, whether the response applies + to a wider range of IP addresses than what was included in the RI + request. + + The cacheability of the response is indicated using the standard HTTP + Cache-Control mechanisms. + +4.2. JSON Encoding of RI Requests and Responses + + The body of RI requests and responses is a JSON object [RFC7159] that + contains a dictionary of key:value pairs that MUST conform to + [RFC7493]. Senders MUST encode all (top-level object and sub-object) + keys specified in this document in lowercase. Receivers MUST ignore + any keys that are unknown or invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 9] + +RFC 7975 Request Routing Redirection October 2016 + + + The following table defines the top-level keys and indicates whether + they are applicable to RI requests, RI responses, or both: + + +----------+------------------+-------------------------------------+ + | Key | Request/Response | Description | + +----------+------------------+-------------------------------------+ + | dns | Both | The attributes of the UA's DNS | + | | | request or the attributes of the | + | | | RT(s) to return in a DNS response. | + | | | | + | http | Both | The attributes of the UA's HTTP | + | | | request or the attributes of the RT | + | | | to return in an HTTP response. | + | | | | + | scope | Response | The scope of the response (if it is | + | | | cacheable). For example, whether | + | | | the response applies to a wider | + | | | range of IP addresses than what was | + | | | included in the RI request. | + | | | | + | error | Response | Additional details if the response | + | | | is an error response. | + | | | | + | cdn-path | Both | A List of Strings. Contains a list | + | | | of the CDN Provider IDs of previous | + | | | CDNs that have participated in the | + | | | request routing for the associated | + | | | User Agent request. On RI requests, | + | | | it contains the list of previous | + | | | CDNs that this RI request has | + | | | passed through. On RI responses, it | + | | | contains the list of CDNs that were | + | | | involved in obtaining the final | + | | | redirection included in the RI | + | | | response. See Section 4.8. | + | | | | + | max-hops | Request | Integer specifying the maximum | + | | | number of hops (CDN Provider IDs) | + | | | this request is allowed to be | + | | | propagated along. This allows the | + | | | uCDN to coarsely constrain the | + | | | latency of the request routing | + | | | chain. | + +----------+------------------+-------------------------------------+ + + Table 1: Top-Level Keys in RI Requests/Responses + + + + + +Niven-Jenkins, et al. Standards Track [Page 10] + +RFC 7975 Request Routing Redirection October 2016 + + + A single request or response MUST contain only one of the dns or http + keys. Requests MUST contain a cdn-path key and responses MAY contain + a cdn-path key. If the max-hops key is not present, then there is no + limit on the number of CDN hops that the RI request can be propagated + along. If the first uCDN does not wish the RI request to be + propagated beyond the dCDN it is making the request to, then the uCDN + MUST set max-hops to 1. + + The cdn-path MAY be reflected back in RI responses, although doing so + could expose information to the uCDN that a dCDN may not wish to + expose (for example, the existence of business relationships between + a dCDN and other CDNs). + + If the cdn-path is reflected back in the RI response, it MUST contain + the value of cdn-path received in the associated RI request with the + final dCDN's CDN Provider ID appended. Transit CDNs MAY remove the + cdn-path from RI responses but MUST NOT modify the cdn-path in other + ways. + + The presence of an error key within a response that also contains + either a dns or http key does not automatically indicate that the RI + request was unsuccessful as the error key MAY be used for + communicating additional (e.g., debugging) information. When a + response contains an error key as well as either a dns or http key, + the error-code SHOULD be 1xx (e.g., 100). See Section 4.7 for more + details about encoding error information in RI responses. + + All implementations that support IPv4 addresses MUST support the + encoding specified by the 'IPv4address' rule in Section 3.2.2 of + [RFC3986]. Likewise, implementations that support IPv6 addresses + MUST support all IPv6 address formats specified in [RFC4291]. Server + implementations SHOULD use IPv6 address formats specified in + [RFC5952]. + +4.3. MIME Media Types Used by the RI Interface + + RI requests MUST use a MIME media type of application/cdni as + specified in [RFC7736], with the Payload Type (ptype) parameter set + to 'redirection-request'. + + RI responses MUST use a MIME media type of application/cdni as + specified in [RFC7736], with the Payload Type (ptype) parameter set + to 'redirection-response'. + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 11] + +RFC 7975 Request Routing Redirection October 2016 + + +4.4. DNS Redirection + + The following sections provide detailed descriptions of the + information that should be passed in RI requests and responses for + DNS redirection. + +4.4.1. DNS Redirection Requests + + For DNS-based redirection, the uCDN needs to pass the following + information to the dCDN in the RI request: + + o The IP address of the DNS resolver that made the DNS request to + the uCDN. + + o The type of DNS query made (usually either A or AAAA). + + o The class of DNS query made (usually IN). + + o The fully qualified domain name for which DNS redirection is being + requested. + + o The IP address or prefix of the User Agent (if known to the uCDN). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 12] + +RFC 7975 Request Routing Redirection October 2016 + + + The preceding information is encoded as a set of key:value pairs + within the dns dictionary as follows: + + +-------------+---------+-----------+-------------------------------+ + | Key | Value | Mandatory | Description | + +-------------+---------+-----------+-------------------------------+ + | resolver-ip | String | Yes | The IP address of the UA's | + | | | | DNS resolver. | + | | | | | + | qtype | String | Yes | The type of DNS query made by | + | | | | the UA's DNS resolvers in | + | | | | uppercase. The value of this | + | | | | field SHALL be set to either | + | | | | 'A' or 'AAAA'. | + | | | | | + | qclass | String | Yes | The class of DNS query made | + | | | | in uppercase (IN, etc.). | + | | | | | + | qname | String | Yes | The fully qualified domain | + | | | | name being queried. | + | | | | | + | c-subnet | String | No | The IP address (or prefix) of | + | | | | the UA in Classless Inter- | + | | | | Domain Routing (CIDR) format. | + | | | | | + | dns-only | Boolean | No | If True, then dCDN MUST only | + | | | | use DNS redirection and MUST | + | | | | include RTs to one or more | + | | | | surrogates in any successful | + | | | | RI response. CDNs MUST | + | | | | include the dns-only property | + | | | | set to True on any cascaded | + | | | | RI requests. Defaults to | + | | | | False. | + +-------------+---------+-----------+-------------------------------+ + + Table 2 + + An RI request for DNS-based redirection MUST include a dns + dictionary. This dns dictionary MUST contain the following keys: + resolver-ip, qtype, qclass, and qname; the value of each MUST be the + value of the appropriate part of the User Agent's DNS query/request. + For internationalized domain names containing non-ASCII characters, + the value of the qname field MUST be the ASCII-compatible encoded + (ACE) representation (A-label) of the domain name [RFC5890]. + + + + + + +Niven-Jenkins, et al. Standards Track [Page 13] + +RFC 7975 Request Routing Redirection October 2016 + + + An example RI request (uCDN->dCDN) for DNS-based redirection is as + follows: + + POST /dcdn/ri HTTP/1.1 + Host: rr1.dcdn.example.net + Content-Type: application/cdni; ptype=redirection-request + Accept: application/cdni; ptype=redirection-response + + { + "dns" : { + "resolver-ip" : "192.0.2.1", + "c-subnet" : "198.51.100.0/24", + "qtype" : "A", + "qclass" : "IN", + "qname" : "www.example.com" + }, + "cdn-path": ["AS64496:0"], + "max-hops": 3 + } + +4.4.2. DNS Redirection Responses + + For a successful DNS-based redirection, the dCDN needs to return one + of the following to the uCDN in the RI response: + + o The IP address(es) of (or the CNAME of) RTs that are dCDN + surrogates (if the dCDN is performing DNS-based redirection + directly to a surrogate); or + + o The IP address(es) of (or the CNAME of) RTs that are Request + Routers (if the dCDN will perform request redirection itself). A + dCDN MUST NOT return an RT that is a Request Router if the dns- + only key is set to True in the RI request. + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 14] + +RFC 7975 Request Routing Redirection October 2016 + + + The preceding information is encoded as a set of key:value pairs + within the dns dictionary as follows: + + +-------+-----------+-----------+-----------------------------------+ + | Key | Value | Mandatory | Description | + +-------+-----------+-----------+-----------------------------------+ + | rcode | Integer | Yes | DNS response code (see | + | | | | [RFC6895]). | + | | | | | + | name | String | Yes | The fully qualified domain name | + | | | | the response relates to. | + | | | | | + | a | List of | No | Set of IPv4 Addresses of RT(s). | + | | String | | | + | | | | | + | aaaa | List of | No | Set of IPv6 Addresses of RT(s). | + | | String | | | + | | | | | + | cname | List of | No | Set of fully qualified domain | + | | String | | names of RT(s). | + | | | | | + | ttl | Integer | No | TTL in seconds of DNS response. | + | | | | Default is 0. | + +-------+-----------+-----------+-----------------------------------+ + + Table 3 + + A successful RI response for DNS-based redirection MUST include a dns + dictionary and MAY include an error dictionary (see Section 4.7). An + unsuccessful RI response for DNS-based redirection MUST include an + error dictionary. If a dns dictionary is included in the RI + response, it MUST include the rcode and name keys and it MUST include + at least one of the following keys: a, aaaa, or cname. The dns + dictionary MAY include both a and aaaa keys. If the dns dictionary + contains a cname key, it MUST NOT contain either an a or aaaa key. + For internationalized domain names containing non-ASCII characters, + the value of the cname field MUST be the ACE representation (A-label) + of the domain name. + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 15] + +RFC 7975 Request Routing Redirection October 2016 + + + An example of a successful RI response (dCDN->uCDN) for DNS-based + redirection with both a and aaaa keys is listed below: + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + + { + "dns" : { + "rcode" : 0, + "name" : "www.example.com", + "a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"], + "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], + "ttl" : 60 + } + } + + A further example of a successful RI response (dCDN->uCDN) for DNS- + based redirection is listed below, in this case with a cname key + containing the FQDN of the RT. + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + + { + "dns" : { + "rcode" : 0, + "name" : "www.example.com", + "cname" : ["rr1.dcdn.example"], + "ttl" : 20 + } + } + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 16] + +RFC 7975 Request Routing Redirection October 2016 + + +4.5. HTTP Redirection + + The following sections provide detailed descriptions of the + information that should be passed in RI requests and responses for + HTTP redirection. + + The dictionary keys used in HTTP Redirection requests and responses + use the following conventions for their prefixes: + + o c- is prefixed to keys for information related to the Client (User + Agent). + + o cs- is prefixed to keys for information passed by the Client (User + Agent) to the Server (uCDN). + + o sc- is prefixed to keys for information to be passed by the Server + (uCDN) to the Client (User Agent). + +4.5.1. HTTP Redirection Requests + + For HTTP-based redirection, the uCDN needs to pass the following + information to the dCDN in the RI request: + + o The IP address of the User Agent. + + o The URI requested by the User Agent. + + o The HTTP method requested by the User Agent. + + o The HTTP version number requested by the User Agent. + + The uCDN may also decide to pass the presence and value of particular + HTTP headers included in the User Agent request to the dCDN. + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 17] + +RFC 7975 Request Routing Redirection October 2016 + + + The preceding information is encoded as a set of key:value pairs + within the http dictionary as follows: + + +-------------------+--------+-----------+--------------------------+ + | Key | Value | Mandatory | Description | + +-------------------+--------+-----------+--------------------------+ + | c-ip | String | Yes | The IP address of the | + | | | | UA. | + | | | | | + | cs-uri | String | Yes | The Effective Request | + | | | | URI [RFC7230] requested | + | | | | by the UA. | + | | | | | + | cs-method | String | Yes | The method part of the | + | | | | request-line as defined | + | | | | in Section 3.1.1 of | + | | | | [RFC7230]. | + | | | | | + | cs-version | String | Yes | The HTTP-version part of | + | | | | the request-line as | + | | | | defined in Section 3.1.1 | + | | | | of [RFC7230]. | + | | | | | + | cs-(<headername>) | String | No | The field-value of the | + | | | | HTTP header field named | + | | | | <HeaderName> as a | + | | | | string, for example, | + | | | | cs-(cookie) would | + | | | | contain the value of the | + | | | | HTTP Cookie header from | + | | | | the UA request. | + +-------------------+--------+-----------+--------------------------+ + + Table 4 + + An RI request for HTTP-based redirection MUST include an http + dictionary. This http dictionary MUST contain the following keys: + c-ip, cs-method, cs-version, and cs-uri; the value of each MUST be + the value of the appropriate part of the User Agent's HTTP request. + + The http dictionary of an RI request MUST contain a maximum of one + cs-(<headername>) key for each unique header field-name (HTTP header + field). <headername> MUST be identical to the equivalent HTTP header + field-name encoded in all lowercase. + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 18] + +RFC 7975 Request Routing Redirection October 2016 + + + In the case where the User Agent request includes multiple HTTP + header fields with the same field-name, it is RECOMMENDED that the + uCDN combine these different HTTP headers into a single value + according to Section 3.2.2 of [RFC7230]. However, because of the + plurality of already defined HTTP header fields and the inconsistency + of some of these header fields concerning the combination mechanism + defined in RFC 7230, the uCDN MAY have to deviate from using the + combination mechanism where appropriate. For example, it might only + send the contents of the first occurrence of the HTTP Headers + instead. + + An example RI request (uCDN->dCDN) for HTTP-based redirection is as + follows: + + POST /dcdn/rrri HTTP/1.1 + Host: rr1.dcdn.example.net + Content-Type: application/cdni; ptype=redirection-request + Accept: application/cdni; ptype=redirection-response + + { + "http": { + "c-ip": "198.51.100.1", + "cs-uri": "http://www.example.com", + "cs-version": "HTTP/1.1", + "cs-method": "GET" + }, + "cdn-path": ["AS64496:0"], + "max-hops": 3 + } + +4.5.2. HTTP Redirection Responses + + For a successful HTTP-based redirection, the dCDN needs to return one + of the following to the uCDN in the RI response: + + o A URI pointing to an RT that is the selected dCDN surrogate(s) (if + the dCDN is performing HTTP-based redirection directly to a + surrogate); or + + o A URI pointing to an RT that is a Request Router (if the dCDN will + perform request redirection itself). + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 19] + +RFC 7975 Request Routing Redirection October 2016 + + + The preceding information is encoded as a set of key:value pairs + within the http dictionary as follows: + + +-------------------+---------+-----------+-------------------------+ + | Key | Value | Mandatory | Description | + +-------------------+---------+-----------+-------------------------+ + | sc-status | Integer | Yes | The status-code part of | + | | | | the status-line as | + | | | | defined in Section | + | | | | 3.1.2 of [RFC7230] to | + | | | | return to the UA | + | | | | (usually set to 302). | + | | | | | + | sc-version | String | Yes | The HTTP-version part | + | | | | of the status-line as | + | | | | defined in Section | + | | | | 3.1.2 of [RFC7230] to | + | | | | return to the UA. | + | | | | | + | sc-reason | String | Yes | The reason-phrase part | + | | | | of the status-line as | + | | | | defined in Section | + | | | | 3.1.2 of [RFC7230] to | + | | | | return to the UA. | + | | | | | + | cs-uri | String | Yes | The URI requested by | + | | | | the UA/client. | + | | | | | + | sc-(location) | String | Yes | The contents of the | + | | | | Location header to | + | | | | return to the UA (i.e., | + | | | | a URI pointing to the | + | | | | RT(s)). | + | | | | | + | sc-(<headername>) | String | No | The field-value of the | + | | | | HTTP header field named | + | | | | <HeaderName> to return | + | | | | to the UA. For example, | + | | | | sc-(expires) would | + | | | | contain the value of | + | | | | the HTTP Expires | + | | | | header. | + +-------------------+---------+-----------+-------------------------+ + + Table 5 + + + + + + +Niven-Jenkins, et al. Standards Track [Page 20] + +RFC 7975 Request Routing Redirection October 2016 + + + Note: The sc-(location) key in the preceding table is an example of + sc-(<headername>) that has been called out separately as its presence + is mandatory in RI responses. + + A successful RI response for HTTP-based redirection MUST include an + http dictionary and MAY include an error dictionary (see + Section 4.7). An unsuccessful RI response for HTTP-based redirection + MUST include an error dictionary. If an http dictionary is included + in the RI response, it MUST include at least the following keys: + sc-status, sc-version, sc-reason, cs-uri, and sc-(location). + + The http dictionary of an RI response MUST contain a maximum of one + sc-(<headername>) key for each unique header field-name (HTTP header + field). <headername> MUST be identical to the equivalent HTTP header + field-name encoded in all lowercase. + + The uCDN MAY decide to not return, override, or alter any or all of + the HTTP headers defined by sc-(<headername>) keys before sending the + HTTP response to the UA. It should be noted that in some cases, + sending the HTTP Headers indicated by the dCDN transparently on to + the UA might result in, for the uCDN, undesired behavior. As an + example, the dCDN might include sc-(cache-control), + sc-(last-modified), and sc-(expires) keys in the http dictionary, + through which the dCDN may try to influence the cacheability of the + response by the UA. If the uCDN would pass these HTTP headers on to + the UA, this could mean that further requests from the uCDN would go + directly to the dCDN, bypassing the uCDN and any logging it may + perform on incoming requests. Therefore, the uCDN is recommended to + carefully consider which HTTP headers to pass on, and which to either + override or not pass on at all. + + An example of a successful RI response (dCDN->uCDN) for HTTP-based + redirection is a follows: + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + + { + "http": { + "sc-status": 302, + "sc-version": "HTTP/1.1", + "sc-reason": "Found", + "cs-uri": "http://www.example.com" + "sc-(location)": + "http://sur1.dcdn.example/ucdn/example.com", + } + } + + + +Niven-Jenkins, et al. Standards Track [Page 21] + +RFC 7975 Request Routing Redirection October 2016 + + +4.6. Cacheability and Scope of Responses + + RI responses may be cacheable. As long as a cached RI response is + not stale according to standard HTTP Cache-Control or other + applicable mechanisms, it may be reused by the uCDN in response to + User Agent requests without sending another RI request to the dCDN. + + An RI response MUST NOT be reused unless the request from the User + Agent would generate an identical RI request to the dCDN as the one + that resulted in the cached RI response (except for the c-ip field + provided that the User Agent's c-ip is covered by the scope in the + original RI response, as elaborated upon below). + + Additionally, although RI requests only encode a single User Agent + request to be redirected, there may be cases where a dCDN wishes to + indicate to the uCDN that the RI response can be reused for other + User Agent requests without the uCDN having to make another request + via the RI. For example, a dCDN may know that it will always select + the same surrogates for a given set of User Agent IP addresses and in + order to reduce request volume across the RI or to remove the + additional latency associated with an RI request, the dCDN may wish + to indicate that set of User Agent IP addresses to the uCDN in the + initial RI response. This is achieved by including an optional scope + dictionary in the RI response. + + Scope is encoded as a set of key:value pairs within the scope + dictionary as follows: + + +---------+--------+-----------+------------------------------------+ + | Key | Value | Mandatory | Description | + +---------+--------+-----------+------------------------------------+ + | iprange | List | No | A List of IP subnets in CIDR | + | | of | | notation that this RI response can | + | | String | | be reused for, provided the RI | + | | | | response is still considered | + | | | | fresh. | + +---------+--------+-----------+------------------------------------+ + + Table 6 + + If a uCDN has multiple cached responses with overlapping scopes and a + UA request comes in for which the User Agent's IP matches with the IP + subnets in multiple of these cached responses, the uCDN SHOULD use + the most recent cached response when determining the appropriate RI + response to use. + + + + + + +Niven-Jenkins, et al. Standards Track [Page 22] + +RFC 7975 Request Routing Redirection October 2016 + + + The following is an example of a DNS redirection response from + Section 4.4.2 that is cacheable by the uCDN for 30 seconds and can be + returned to any User Agent with an IPv4 address in 198.51.100.0/24. + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + Cache-Control: public, max-age=30 + + { + "dns" : { + "rcode" : 0, + "name" : "www.example.com", + "a" : ["203.0.113.200", "203.0.113.201"], + "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"], + "ttl" : 60 + } + "scope" : { + "iprange" : ["198.51.100.0/24"] + } + } + + The following is an example of an HTTP redirection response from + Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be + returned to any User Agent with an IPv4 address in 198.51.100.0/24. + + Note: The response to the UA is only valid for 30 seconds, whereas + the uCDN can cache the RI response for 60 seconds. + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + Cache-Control: public, max-age=60 + + { + "http": { + "sc-status": 302, + "cs-uri": "http://www.example.com" + "sc-(location)": + "http://sur1.dcdn.example/ucdn/example.com", + "sc-(cache-control)" : "public, max-age=30" + } + "scope" : { + "iprange" : ["198.51.100.0/24"] + } + } + + + + + +Niven-Jenkins, et al. Standards Track [Page 23] + +RFC 7975 Request Routing Redirection October 2016 + + +4.7. Error Responses + + From a uCDN perspective, there are two types of errors that can be + the result of the transmission of an RI request to a dCDN: + + 1. An HTTP protocol error signaled via an HTTP status code, + indicating a problem with the reception or parsing of the RI + request or the generation of the RI response by the dCDN, and + + 2. An RI-level error specified in an RI response message. + + This section deals with the latter type. The former type is outside + the scope of this document. + + There are numerous reasons for a dCDN to be unable to return an + affirmative RI response to a uCDN. Reasons may include both dCDN + internal issues such as capacity problems, as well as reasons outside + the influence of the dCDN, such as a malformed RI request. To aid + with diagnosing the cause of errors, RI responses SHOULD include an + error dictionary to provide additional information to the uCDN as to + the reason/cause of the error. The intention behind the error + dictionary is to aid with either manual or automatic diagnosis of + issues. The resolution of such issues is outside the scope of this + document; this document does not specify any consequent actions a + uCDN should take upon receiving a particular error-code. + + Error information (if present) is encoded as a set of key:value pairs + within a JSON-encoded error dictionary as follows: + + +------------+---------+-----------+--------------------------------+ + | Key | Value | Mandatory | Description | + +------------+---------+-----------+--------------------------------+ + | error-code | Integer | Yes | A three-digit numeric code | + | | | | defined by the server to | + | | | | indicate the error(s) that | + | | | | occurred. | + | | | | | + | reason | String | No | A string providing further | + | | | | information related to the | + | | | | error. | + +------------+---------+-----------+--------------------------------+ + + Table 7 + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 24] + +RFC 7975 Request Routing Redirection October 2016 + + + The first digit of the error-code defines the class of error. There + are 5 classes of errors distinguished by the first digit of the + error-code: + + 1xx: Informational (no error): The response should not be + considered an error by the uCDN, which may proceed by redirecting + the UA according to the values in the RI response. The error-code + and accompanying description may be used for informational + purposes, e.g., for logging. + + 2xx: Reserved. + + 3xx: Reserved. + + 4xx: uCDN error: The dCDN cannot or will not process the request + due to something that is perceived to be a uCDN error, for + example, the RI request could not be parsed successfully by the + dCDN. The last two-digits may be used to more specifically + indicate the source of the problem. + + 5xx: dCDN error: Indicates that the dCDN is aware that it has + erred or is incapable of satisfying the RI request for some + reason, for example, the dCDN was able to parse the RI request but + encountered an error for some reason. Examples include the dCDN + not being able to retrieve the associated metadata or the dCDN + being out of capacity. + + The following error-codes are defined and maintained by IANA (see + Section 6). + + Error-codes with a "Reason" of "<reason>" do not have a defined value + for their 'reason'-key. Depending on the error-code semantics, the + value of this field may be determined dynamically. + + +------+--------------+---------------------------------------------+ + | Code | Reason | Description | + +------+--------------+---------------------------------------------+ + | 100 | <reason> | Generic informational error-code meant for | + | | (see | carrying a human-readable string | + | | Description) | | + | | | | + | 400 | <reason> | Generic error-code for uCDN errors where | + | | (see | the dCDN cannot or will not process the | + | | Description) | request due to something that is perceived | + | | | to be a uCDN error. The reason field may | + | | | be used to provide more details about the | + | | | source of the error. | + | | | | + + + +Niven-Jenkins, et al. Standards Track [Page 25] + +RFC 7975 Request Routing Redirection October 2016 + + + | 500 | <reason> | Generic error-code for dCDN errors where | + | | (see | the dCDN is aware that it has erred or is | + | | Description) | incapable of satisfying the RI request for | + | | | some reason. The reason field may be used | + | | | to provide more details about the source of | + | | | the error. | + | | | | + | 501 | Unable to | The dCDN is unable to retrieve the metadata | + | | retrieve | associated with the content requested by | + | | metadata | the UA. This may indicate a configuration | + | | | error or that the content requested by the | + | | | UA does not exist. | + | | | | + | 502 | Loop | The dCDN detected a redirection loop (see | + | | detected | Section 4.8). | + | | | | + | 503 | Maximum hops | The dCDN detected the maximum number of | + | | exceeded | redirection hops exceeding max-hops (see | + | | | Section 4.8). | + | | | | + | 504 | Out of | The dCDN does not currently have sufficient | + | | capacity | capacity to handle the UA request. | + | | | | + | 505 | Delivery | The dCDN does not support the (set of) | + | | protocol not | delivery protocols indicated in the CDNI | + | | supported | Metadata of the content requested by the | + | | | UA. | + | | | | + | 506 | Redirection | The dCDN does not support the requested | + | | protocol not | redirection protocol. This error-code is | + | | supported | also used when the RI request has the dns- | + | | | only flag set to True and the dCDN is not | + | | | supported or is not prepared to return an | + | | | RT of a surrogate directly. | + +------+--------------+---------------------------------------------+ + + Table 8 + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 26] + +RFC 7975 Request Routing Redirection October 2016 + + + The following is an example of an unsuccessful RI response + (dCDN->uCDN) for a DNS-based User Agent request: + + HTTP/1.1 500 Internal Server Error + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + Cache-Control: private, no-cache + + { + "error" : { + "error-code" : 504, + "description" : "Out of capacity" + } + } + + The following is an example of a successful RI response (dCDN->uCDN) + for an HTTP-based User Agent request containing an error dictionary + for informational purposes: + + HTTP/1.1 200 OK + Date: Mon, 06 Aug 2012 18:41:38 GMT + Content-Type: application/cdni; ptype=redirection-response + Cache-Control: private, no-cache + + { + "http": { + "sc-status": 302, + "sc-version": "HTTP/1.1", + "sc-reason": "Found", + "cs-uri": "http://www.example.com" + "sc-(location)": + "http://sur1.dcdn.example/ucdn/example.com", + }, + "error" : { + "error-code" : 100, + "description" : + "This is a human-readable message meant for debugging purposes" + } + } + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 27] + +RFC 7975 Request Routing Redirection October 2016 + + +4.8. Loop Detection and Prevention + + In order to prevent and detect RI request loops, each CDN MUST insert + its CDN Provider ID into the cdn-path key of every RI request it + originates or cascades. When receiving RI requests, a dCDN MUST + check the cdn-path and reject any RI requests that already contain + the dCDN's Provider ID in the cdn-path. Transit CDNs MUST NOT + propagate to any downstream CDNs if the number of CDN Provider IDs in + cdn-path (before adding its own Provider ID) is equal to or greater + than max-hops. + + The CDN Provider ID uniquely identifies each CDN Provider during the + course of request routing redirection. It consists of the characters + AS followed by the CDN Provider's AS number, then a colon (':') and + an additional qualifier that is used to guarantee uniqueness in case + a particular AS has multiple independent CDNs deployed; for example, + "AS64496:0". + + If a dCDN receives an RI request whose cdn-path already contains that + dCDN's Provider ID, the dCDN MUST send an RI error response that + SHOULD include an error-code of 502. + + If a dCDN receives an RI request where the number of CDN Provider IDs + in cdn-path is greater than max-hops, the dCDN MUST send an RI error + response that SHOULD include an error-code of 503. + + It should be noted that the loop detection and prevention mechanisms + described above only cover preventing and detecting loops within the + RI itself. Besides loops within the RI itself, there is also the + possibility of loops in the data plane; for example, if the IP + address(es) or URI(s) returned in RI responses do not resolve + directly to a surrogate in the final dCDN, there is the possibility + that a User Agent may be continuously redirected through a loop of + CDNs. The specification of solutions to address data-plane request + redirection loops between CDNs is outside of the scope of this + document. + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 28] + +RFC 7975 Request Routing Redirection October 2016 + + +5. Security Considerations + + Information passed over the RI could be considered personal or + sensitive, for example, RI requests contain parts of a User Agent's + original request and RI responses reveal information about the dCDN's + policy for which surrogates should serve which content/user + locations. + + The RI interface also provides a mechanism whereby a uCDN could probe + a dCDN and infer the dCDN's edge topology by making repeated RI + requests for different content and/or UA IP addresses and correlating + the responses from the dCDN. Additionally, the ability for a dCDN to + indicate that an RI response applies more widely than the original + request (via the scope dictionary) may significantly reduce the + number of RI requests required to probe and infer the dCDN's edge + topology. + + The same information could be obtained in the absence of the RI + interface, but it could be more difficult to gather as it would + require a distributed set of machines with a range of different IP + addresses, each making requests directly to the dCDN. However, the + RI facilitates easier collection of such information as it enables a + single client to query the dCDN for a redirection/surrogate selection + on behalf of any UA IP address. + +5.1. Authentication, Authorization, Confidentiality, and Integrity + Protection + + An implementation of the CDNI Redirection interface MUST support TLS + transport as per [RFC2818] and [RFC7230]. The use of TLS for + transport of the CDNI Redirection interface messages allows the dCDN + and uCDN to authenticate each other. Once they have mutually + authenticated each other, it allows: + + o The dCDN and uCDN to authorize each other (to ensure they are + transmitting/receiving CDNI Redirection messages to/from an + authorized CDN); + + o CDNI Redirection interface messages to be transmitted with + confidentiality; and + + o The integrity of the CDNI Redirection interface messages to be + protected during the exchange. + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 29] + +RFC 7975 Request Routing Redirection October 2016 + + + In an environment where any such protection is required, mutually + authenticated encrypted transport MUST be used to ensure + confidentiality of the redirection information; to do so, TLS MUST be + used (including authentication of the remote end) by the server side + (dCDN) and the client side (uCDN) of the CDNI Redirection interface. + + When TLS is used, the general TLS usage guidance in [RFC7525] MUST be + followed. + +5.2. Privacy + + Information passed over the RI ought to be considered personal and + sensitive. In particular, parts of a User Agent's original request, + most notably the UA's IP address and requested URI, are transmitted + over the RI to the dCDN. The use of mutually authenticated TLS, as + described in the previous section, prevents any other party than the + authorized dCDN from gaining access to this information. + + Regardless of whether the uCDN and dCDN use the RI, a successful + redirect from a uCDN to a dCDN will make that dCDN aware of the UA's + IP address. As such, the fact that this information is transmitted + across the RI does not allow the dCDN to learn new information. On + the other hand, if a uCDN uses the RI to check with multiple + candidate dCDNs, those candidates that do not end up getting + redirected to do obtain information regarding end-user IP addresses + and requested URIs that they would not have if the RI not been used. + + While it is technically possible to mask some information in the RI + Request, such as the last bits of the UA IP address, it is important + to note that this will reduce the effectiveness of the RI in certain + cases. CDN deployments need to strike a balance between end-user + privacy and the features impacted by such masking. This balance is + likely to vary from one deployment to another. As an example, when + the UA and its DNS resolver is behind a Carrier-grade NAT, and the RI + is used to find an appropriate delivery node behind the same NAT, the + full IP address might be necessary. Another potential issue when + using IP anonymization is that it is no longer possible to correlate + an RI Request with a subsequent UA request. + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 30] + +RFC 7975 Request Routing Redirection October 2016 + + +6. IANA Considerations + +6.1. CDNI Payload Type Parameter Registrations + + IANA has registered the following two new Payload Types in the + "Content Delivery Network Interconnection (CDNI) Parameters" registry + for use with the application/cdni MIME media type. + + +----------------------+---------------+ + | Payload Type | Specification | + +----------------------+---------------+ + | redirection-request | RFC 7975 | + | | | + | redirection-response | RFC 7975 | + +----------------------+---------------+ + + Table 9 + +6.1.1. CDNI RI Redirection Request Payload Type + + Purpose: The purpose of this payload type is to distinguish RI + request messages. + + Interface: RI + + Encoding: See Section 4.4.1 and Section 4.5.1 + +6.1.2. CDNI RI Redirection Response Payload Type + + Purpose: The purpose of this payload type is to distinguish RI + response messages. + + Interface: RI + + Encoding: See Section 4.4.2 and Section 4.5.2 + +6.2. RI Error Response Registry + + IANA has created a new "CDNI RI Error response code" subregistry + within the "Content Delivery Network Interconnection (CDNI) + Parameters" registry. The "CDNI RI Error response code" namespace + defines the valid values for the error-code key in RI error + responses. The CDNI RI Error response code MUST be a three-digit + integer. + + Additions to the "RI Error response registry" will be made via + "Specification Required" as defined in [RFC5226]. + + + + +Niven-Jenkins, et al. Standards Track [Page 31] + +RFC 7975 Request Routing Redirection October 2016 + + + The Designated Expert will verify that new error-code registrations + do not duplicate existing error-code definitions (in name or + functionality), ensure that the new error-code is in accordance with + the error classes defined in Section 4.7 of this document, prevent + gratuitous additions to the namespace, and prevent any additions to + the namespace that would impair the interoperability of CDNI + implementations. + + New registrations are required to provide the following information: + + Code: A three-digit numeric error-code, in accordance with the + error classes defined in Section 4.7 of this document. + + Reason: A string that provides further information related to the + error that will be included in the JSON error dictionary with the + 'reason'-key. Depending on the error-code semantics, the value of + this field may be determined dynamically. In that case, the + registration should set this value to '<reason>' and define its + semantics in the description field. + + Description: A brief description of the error-code semantics. + + Specification: Reference to the specification that defines the + error-code in more detail. + + The entries in Table 8 are registered by this document, with the + value of the 'Specification' field set to RFC 7975 (this document). + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <http://www.rfc-editor.org/info/rfc4291>. + + + + + + +Niven-Jenkins, et al. Standards Track [Page 32] + +RFC 7975 Request Routing Redirection October 2016 + + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + <http://www.rfc-editor.org/info/rfc5952>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <http://www.rfc-editor.org/info/rfc7230>. + + [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March + 2014, <http://www.rfc-editor.org/info/rfc7159>. + + [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, + April 2013, <http://www.rfc-editor.org/info/rfc6895>. + + [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, + DOI 10.17487/RFC7493, March 2015, + <http://www.rfc-editor.org/info/rfc7493>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <http://www.rfc-editor.org/info/rfc7525>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content + Distribution Network Interconnection (CDNI) Problem + Statement", RFC 6707, DOI 10.17487/RFC6707, September + 2012, <http://www.rfc-editor.org/info/rfc6707>. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + <http://www.rfc-editor.org/info/rfc2818>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <http://www.rfc-editor.org/info/rfc5890>. + + + + + +Niven-Jenkins, et al. Standards Track [Page 33] + +RFC 7975 Request Routing Redirection October 2016 + + + [RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol + (RTMP) specification", December 2012, + <http://www.adobe.com/go/spec_rtmp>. + +7.2. Informative References + + [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution + Network Interconnection (CDNI) Requirements", RFC 7337, + DOI 10.17487/RFC7337, August 2014, + <http://www.rfc-editor.org/info/rfc7337>. + + [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., + "Framework for Content Distribution Network + Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, + August 2014, <http://www.rfc-editor.org/info/rfc7336>. + + [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) + Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, + December 2015, <http://www.rfc-editor.org/info/rfc7736>. + +Acknowledgements + + The authors would like to thank Taesang Choi, Francois Le Faucheur, + Matt Miller, Scott Wainner, and Kevin J. Ma for their valuable + comments and input to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 34] + +RFC 7975 Request Routing Redirection October 2016 + + +Contributors + + The following persons have participated as co-authors to this + document: + + Wang Danhua + Huawei + Email: wangdanhua@huawei.com + + He Xiaoyan + Huawei + Email: hexiaoyan@huawei.com + + Ge Chen + China Telecom + Email: cheng@gsta.com + + Ni Wei + China Mobile + Email: niwei@chinamobile.com + + Yunfei Zhang + Email: hishigh@gmail.com + + Spencer Dawkins + Huawei + Email: spencer@wonderhamster.org + +Authors' Addresses + + Ben Niven-Jenkins (editor) + Nokia + 3 Ely Road + Milton, Cambridge CB24 6DD + United Kingdom + + Email: ben.niven-jenkins@nokia.com + + + Ray van Brandenburg (editor) + TNO + Anna van Buerenplein 1 + The Hague 2595DA + The Netherlands + + Phone: +31-88-866-7000 + Email: ray.vanbrandenburg@tno.nl + + + + +Niven-Jenkins, et al. Standards Track [Page 35] + |